Real-hardware validation of the WHP dynamic-resolution path from #118, run on this Windows box (gui-demo/xeyes, CHEFER_WHP_TRACE_GPU=1).

What the hardware showed

Resizing the window to 1024×845 produced, in order:

[whp-gpu] host window resized; requesting guest mode 1024x845
[whp-gpu] guest GET_DISPLAY_INFO -> 1024x845
[whp-gpu] guest GET_EDID -> 1024x845
[whp-gpu] guest events_clear 0x1

→ the device → config interrupt → guest-driver re-read half works end to end. But scanout flush stayed 1280×800: cage (a fixed-mode kiosk compositor) does not re-modeset on an online mode change. Forcing it via a disconnect→reconnect "replug" does make cage react — by tearing down the output, which exits the interface app and fail_fast kills the whole app. So a live guest re-modeset isn't achievable with cage.

The fix (ship the honest, stable behavior)

Host window resizes freely; the picture scales (StretchDIBits). gui_window drops the pending-resize/timeout machinery (which assumed the guest would re-modeset and briefly paused resize-to-content) for a one-way user_sized latch: once the user resizes, resize-to-content is disabled permanently → the window never snaps back; absolute pointer coords still map by window ratio, so input stays correct.

The device-side config-change signal is kept and unit-tested — correct and future-compatible: swapping cage for a mode-following compositor enables true re-modeset with no device changes. Added CHEFER_WHP_TRACE_GPU traces on GET_DISPLAY_INFO / GET_EDID / events_clear for this diagnosis.

Validation

• whp-helper 120 unit tests green locally (Windows-native build on this box); resize test now asserts the scanout stays enabled (never simulate disconnect).
• End-to-end confirmed on real WHP: window resized to 1024×845 and stayed (no bounce-back), xeyes visible scaled into it (screenshot captured locally).
• Also surfaced a pre-existing, intermittent WHP GUI boot race (guest-agent exits ~0.45s before cage starts, ~1-in-3 boots) — unrelated to this change (unchanged guest-agent binary; same bundle boots fine otherwise); noted here, not fixed in this PR.
• DESIGN/README updated to the validated behavior.

🤖 Generated with Claude Code